fix(librarypath): stop cleanEmpty from panicking on a non-trailing empty entry - #272

O problema

boss install mata o processo com um panic no fim da instalação, depois que todas as dependências já foram resolvidas, baixadas e escritas em disco (boss.json, boss-lock.json e o .dproj já atualizados) — só quebra no passo final de "Updating library path":

♻️ Updating library path...
panic: runtime error: slice bounds out of range [:2:1]

goroutine 1 [running]:
slices.Delete[...](...)
	.../slices/slices.go:223
github.com/hashload/boss/utils/librarypath.cleanEmpty(...)
	.../utils/librarypath/librarypath.go:209
github.com/hashload/boss/utils/librarypath.getNewBrowsingPathsFromDir(...)
	.../utils/librarypath/librarypath.go:236
...
github.com/hashload/boss/internal/core/services/installer.DoInstall(...)
	.../internal/core/services/installer/core.go:135

Causa

cleanEmpty percorre paths com range e apaga elementos vazios via slices.Delete dentro do próprio loop:

func cleanEmpty(paths []string) []string {
	for index, value := range paths {
		if value == "" {
			paths = slices.Delete(paths, index, index+1)
		}
	}
	return paths
}

range paths fixa o tamanho da slice uma vez, no início do loop. Cada slices.Delete encolhe a slice de verdade, mas o loop continua contando contra o tamanho original. Basta existir uma string vazia que não seja o último elemento para o índice do range ultrapassar o tamanho já encolhido — daí o slice bounds out of range.

Reproduzi isso na mão, revertendo só essa função para testar ["a", "", "b"]:

--- FAIL: TestCleanEmpty/single_empty (0.00s)
panic: runtime error: slice bounds out of range [:3:2]
	slices.Delete[...](...)
	github.com/hashload/boss/utils/librarypath.cleanEmpty(...)

Mesmo panic, mesma função — confirma que não precisa de múltiplas entradas vazias, uma só (fora da última posição) já derruba.

cleanEmpty é chamado a partir de getNewBrowsingPathsFromDir, dentro de UpdateLibraryPath, que junta os browsing paths declarados no boss.json de cada dependência instalada num projeto. Qualquer "" que sobre nessa lista acumulada (antes da última posição) derruba o boss install inteiro nesse passo — mesmo com a instalação em si já ter dado certo.

A correção

Reescrevi como o filtro in-place idiomático em Go, sem mutar a slice enquanto itera sobre ela:

func cleanEmpty(paths []string) []string {
	cleaned := paths[:0]
	for _, value := range paths {
		if value != "" {
			cleaned = append(cleaned, value)
		}
	}
	return cleaned
}

Índice de escrita nunca ultrapassa o de leitura, então reaproveitar o array de trás (paths[:0]) é seguro. Removi também o import "slices", que ficou sem uso.

Rastreei os call sites (getNewPathsFromDir, getNewBrowsingPathsFromDir → dproj_util.go / global_util_win.go): em todos, o retorno é reatribuído na mesma variável, então nenhum caller fica com uma slice obsoleta apontando pro array antigo.

Testes

• TestCleanEmpty novo, cobrindo sem vazios, um vazio no meio, vários vazios e todos vazios — os dois últimos casos derrubavam a versão antiga.
• go test ./utils/librarypath/... verde, sem regressão nos testes já existentes do pacote.
• go build ./... e go vet ./... limpos.

🤖 Generated with Claude Code